tea X5"-3-l0 



, X P-002164238 33 J3 25.301 V3.3.0 (1999-12) 



Technical Specification 



3rd Generation Partnership Project; 
Technical Specification Group Radio Access Network; 

Radio Interface Protocol Architecture 
(3G TS 25.301 version 3.3.0) 



LzMZ. V ' v 



(Mi) 



The present document has been developed within the 3' J Generation Partnership Project (3GPP ™) and may be further elaborated for the purposes of 3GPP. 
The present document has not been subject to any approval process by the 3GPP Organisational Partners and shall not be implemented. 

This Specification is provided for future development work within 3GPPonly. The Organisational Partners accept no liability for any use of this Specification. 
Specifications and reports for implementation of the 3GPP™ system should be obtained via the 3GPP Organisational Partners' Publications Offices. 



-N'SDOCID: <XP 216-*23SA_I_> 



3GTS 25.301 V3.3.0 (1999-12) 



3GPP 

Postal address 



3GPP support office address 

650 Route des Lucioles - Sophia Antipolis 
Valbonne - FRANCE 
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 

Internet 

http://www.3gpp.org 



Copyright Notification 



No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© 1999. 3GPP Organizational Partners (ARIB. CWTS, ETSI, Tl. TTA/TTC). 

All rights reserved. 



3GPP 

SNSDOCID: <XP 2164238A_L> 



3G TS 25.301 version 3.3.§ 



Reference 



3TS/TSGR-0225301 U 
Keywords 



Digital cellular telecommunications system, 
Universal Mobile Telecommunication System 
(UMTS), UTRA, IMT-2000 



3G TS 25.301 version 3.3.0 



3 



3G TS 25.301 V3.3.0 (1999-12) 



Contents 

Foreword 5 

1 Scope 6 

2 References * 6 

3 Definitions and abbreviations 7 

3.1 Definitions 7 

3.2 Abbreviations 7 

4 Assu med UMTS Arc h i t ec tu re 8 

5 Radio interface protocol architecture 10 

5 . 1 O veral 1 protocol structure 10 

5.1.1 Service access points and service primitives 11 

5.2 Layer 1 Services antl Functions 12 

5.2.1 LI Services 13 

5 .2. 1 . 1 Transport channels 13 

5.2.2 LI Functions : 14 

5.3 Layer 2 Services and Functions 14 

5.3.1 MAC Services and Functions 14 

5.3.1.1 MAC Services to upper layers : 15 

5.3.1.1.1 Logical channels 15 

5.3.1.1.2 Mapping between logical channels and transport channels 16 

5.3.1.2 MAC functions 13 

5.3.2 RJLC Services and Functions 1 9 

5.3.2.1 Services provided to the upper layer 19 

5.3.2.2 RLC Functions 20 

5.3.3 PDCP Services and Function 20 

5.3.3. 1 PDCP Services provided to upper layers : 20 

5.3.3.2 PDCP Functions 21 

5 .3.4 Broadcast/Multicast Control - Services and functions 2 1 

5.3.4.1 BMC Services • 21 

5.3.4.2 BMC Functions 21 

5.3.5 Data flows through Layer 2 21 

5.3.5.1 Data flow for BCCH mapped to BCH 24 

5.3.5.2 Data flow for BCCH mapped to FACH 24 

5.3.5.3 Data flow for PCCH mapped to PCH 24 

5.3.5.4 Data flow for SCCH mapped to SCH 24 

5.3.5.5 Data flow for CCCH mapped to FACH/RACH 24 

5.3.5.6 Data flow for SHCCH mapped to USCH 24 

5.3.5.7 Data flow for SHCCH mapped to FACH/RACH 25 

5.3.5.8 Data flow for DCCH mapped to FACH/RACH 25 

5.3.5.9 Data flow for DCCH mapped to DSCH 25 

5.3.5. 10 Data flow for DCCH mapped to USCH 25 

5.3.5.1 I Data flow for DCCH mapped to CPCH 25 

5.3.5. 1 2 Data flow for DTCH (non-transparent RLC) mapped to FACH/RACH 25 

5.3.5.13 Data flow for DTCH (non-transparent RLC) mapped to DSCH 25 

5.3.5.14 Data flow for DTCH (non-transparent RLC) mapped to USCH 25 

5.3.5.1 5 Data flow for DTCH (transparent RLC) mapped to DCH 25 

5.3.5.16 Data flow for DTCH (non-transparent RLC) mapped to DCH 26 

5.3.5.17 Data flow for DTCH (non-transparent RLC) mapped to CPCH 26 

5.3.5. 15 Data flow for DCCH mapped to DCH 26 

5.3.5.19 Data flow for CTCH mapped to FACH 26 ^ 

5.4 Layer 3 - Uu Stratum Services and Functions 26 

5.4. 1 Uu Stratum services 26 

5.4.1.1 General Control 26 

5.4.1.2 Notification 26 

5.4. 1 .3 Dedicated Control 27 



3GPP 

vSOCClD: <XP 2l6<t233A_l - > 



3G TS 25.301 version 3.3.I 



4 



3G TS 25.301 V3.3.0 (1999-12) 



5.4.2 RRC functions : £7 

5.5 Interactions between RRC and lower layers in the C plane ..29 

5.6 Protocol termination 30 

5.6. 1 Protocol termination for DCH 30 

5.6.2 Protocol termination for RACH/FACH 30 

5.6.3 Protocol termination for FAUSCH 33 

5.6.4 Protocol termination for CPCH 33 

5.6.5 Protocol termination for DSCH 33 

5.6.5. 1 DSCH definition 33 

5.6.5.2 Resource allocation and UE identification on DSCH 34 

5.6.5.2. 1 Case A (UE requires a downlink TFCI on a DPCCH) 34 

5.6.5.2.2 Case B (UE requires a downlink SHCCH) (TDD only) 34 

5.6.5.3 Model of DSCH in UTRAN 34 

5.6.5.4 Protocol termination : 35 

5.6.6 Protocol termination for transport channel of type USCH 36 

5.6.6.1 . USCH definition 36 

5.6.6.2 Resource allocation and UE identification on USCH 36 

5.6.6.3 Model of USCH in UTRAN 36 

5.6.6.4 Protocol termination 37 

5.6.7 Protocol termination for transport channel of type BCH 38 

5.6.8 Protocol termination for transport channel of type PCH :...38 

5.6.9 Protocol termination for transport channel of type SCH 39 

5.6. 10 Protocol termination for ODCH 39 

5.6.1 1 Protocol termination for ORACH 39 

6 User Identification and RRC Connection Mobility 40 

6. 1 UE identification on the radio interface 40 

6.2 UE connection to UTRAN 4 1 

7 UE modes , 41 

8 Ciphering 41 

8.1 Location of ciphering function in the UTRAN protocol architecture 41 

8.2 Input parameters to the ciphering algorithm 42 

8.2.1 Overview 42 

8.2.2 Ciphering algorithms parameters 42 

8.2.2.1 COUNT 42 

8.2.2.2 Ciphering key, CK 43 

8.2.2.3 BEARER 43 

8.2.2.4 Direction 43 

8.2.2.5 Length 43 

Annex A (informative): Protocol termination 44 

A. 1 Alternative protocol termination for DCH 44 

A.2 Protocol termination for RACH/FACH 44 

Annex B (informative): Change history 47 

History 48 



3GPP 

BNSDOCID <XP 2164238A_!_> 



3G TS 25.301 version 3.3.0 




5 




3G TS 25.301 V3.3.0 (1999-12) 



Foreword 



This Technical Specification has been produced by the 3GPP. 

The contents of the present document are subject to continuing work within the TSG and may change following fcrr 
TSG approval. Should the TSG modify the contents of this TS, it will be re-reieased by the TSG with an identifying 
change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 Indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document shall provide an overview and overall description of the UE-UTRAN radio interface protocol 
architecture as agreed within the 3GPP TSG RAN working group 2. Details of the radio protocols will be specified in 
companion documents. 

UMTS Release 99 shall support the features and functions described in this document generally. However, some 
specific logical channels and transport channels which initially were considered for Release 99, but which were deferred 
to a future UMTS release, have been kept in this specification. 

The channels that are not considered for Release 99 are listed as follows: 

- Fast Uplink Signalling Channel (FAUSCH) 

- ODMA Random Access Channel (ORACH) 

- ODMA Dedicated Channel (ODCH) 

- ODMA Common Control Channel (OCCCH) 

- ODMA Dedicated Control Channel (ODCCH) 

- ODMA Dedicated Traffic Channel (ODTCH) 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 



[I] 3G TS 23.1 10: "UMTS Access Stratum; Services and Functions" 
[2] 3G TS 25.401: "RAN Overall Description" 

[3] 3G TR 25.990: "Vocabulary for the UTRAN" 

[4] 3G TS 25.302: "Services provided by the Physical Layer" 

[5] 3G TS 25.303: "Interlayer Procedures in Connected Mode" 

[6] 3G TS 25.304: "UE Procedures in Idle Mode and Procedures for Cell Reselection in Connected 
Mode " 

[7] 3G TS 25.321: "MAC Protocol Specification" 

[8] 3G TS 25.322: "RLC Protocol Specification" 

(9] 3G TS 25.323: "PDCP Protocol Specification" 

[10] 3G TS 25.324: "BMC Protocol Specification" 

[II] 3G TS 25.33 1 : "RRC Protocol Specification" 

[12] 3G TS 25.224: "Physical Layer Procedures (TDD)" 
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j 1 3 j 3G TS 24.007: "Mobile radio interface signalling layer 3; General aspects" 

[14] 3G TS 33.105: "Cryptographic Algorithm Requirements" 

[15] 3G TS 33. 102: "Security Architecture" 



3.1 



Definitions and abbreviations 



Definitions 



For the purposes of the present document, the terms and definitions given in [3] apply. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ARQ Automatic Repeat Request 

ASC Access Service Class 

BCCH Broadcast Control Channel 

BCH Broadcast Channel 

BMC Broadcast/Multicast Control 

C- Control- 

CC Call Control 

CCCH Common Control Channel 

CCH Control Channel 

CCTrCH Coded Composite Transport Channel 

CN Core Network 

CPCH Common Packet channel 

CRC Cyclic Redundancy Check 

CTCH Common Traffic Channel 

DC Dedicated Control (SAP) 

DCA Dynamic Channel Allocation 

DCCH Dedicated Control Channel 

DCH Dedicated Channel 

DL Downlink 

DRNC Drift Radio Network Controller 

DSCH Downlink Shared Channel 

DTCH Dedicated Traffic Channel 

FACH Forward Link Access Channel 

FAUSCH Fast Uplink Signalling Channel 

FCS Frame Check Sequence 

FDD Frequency Division Duplex 

GC General Control (SAP) 

HO Handover 

ITU International Telecommunication Union 

kbps kilo-bits per second 

LI Layer 1 (physical layer) 

L2 Layer 2 (data link layer) 

L3 Layer 3 (network layer) 

LAC Link Access Control 

LAI Location Area Identity 

MAC Medium Access Control 

MM Mobility Management 

Nt Notification (SAP) 

OCCCH ODMA Common Control Channel 

ODCCH ODMA Dedicated Control Channel 

ODCH ODMA Dedicated Channel 
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ODMA 


Opportunity Driven Multiple Access 


ORACH 


ODMA Random Access Channel 


ODTCH 


ODMA Dedicated Traffic Channel 


PCCH 


Paging Control Channel 


PCH 


Paging Channel 


PDCP 


Packet Data Convergence Protocol 


PDU 


Protocol Data Unit 


PHY 


Physical layer 


PhyCH 


Physical Channels 


PU 


Payload Unit 


RAB 


Radio Access Bearer 


RACH 


Random Access Channel 


RB 


Radio Bearer 


RLC 


Radio Link Control 


RNC 


Radio Network Controller 


RNS 


Radio Network Subsystem 


RNTI 


Radio Network Temporary Identity 


RRC 


Radio Resource Control 


SAP 


Service Access Point 


SCCH 


Synchronisation Control Channel 


SCH 


Synchronisation Channel 


SDU 


Service Data Unit 


SHCCH 


Shared Channel Control Channel 


SRNC 


Serving Radio Network Controller 


SRNS 


Serving Radio Network Subsystem 


TCH 


Traffic Channel 


TDD 


Time Division Duplex 


TFCI 


Transport Format Combination Indicator 


TFI 


Transport Format Indicator 


TMSI 


Temporary Mobile Subscriber Identity 


TPC 


Transmit Power Control 


U- 


User- 


UE 


User Equipment 


UE R 


User Equipment with ODMA relay operation enabled 


UL 


Uplink 


UMTS 


Universal Mobile Telecommunications System 


URA 


UTRAN Registration Area 


USCH 


Uplink Shared Channel 


UTRA 


UMTS Terrestrial Radio Access 


UTRAN 


UMTS Terrestrial Radio Access Network 



4 Assumed UMTS Architecture 

Figure l shows the assumed UMTS architecture as outlined in TS 23.1 10 [I]. The figure shows the UMTS architecture 
in terms of its entities User Equipment (UE), UTRAN and Core Network. The respective reference points Uu (Radio 
Interface) and Iu (CN-UTRAN interface) are shown. The figure illustrates furthermore the high-level functional 
grouping into the Access Stratum and the Non-Access Stratum. 

The Access Stratum offers services through the following Service Access Points (SAP) to the Non-Access Stratum: 

- General Control (GC) SAPs, 
Notification (Nt) SAPs and 

- Dedicated Control (DC) SAPs 

The SAPs are marked with circles in Figure 1. 
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Figure 1: Assumed UMTS Architecture 

This model can be further refined to distinguish the end AS entities, which provide the services to higher layers, from 
the local entities, which provide services over respectively the Uu and the Iu reference point. Figure lb presents the 
refined model. 



444 



Relay 



44=4* Sjjjr 



Uu Stratum 




Iu Stratum 



UE 



UTRAN 



Core Network 



Radio 
(Uu) 



lu 



Figure 1b: Assumed UTRAN Model 

The Uu Stratum block can be further refined as shown in Figure lc: 
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Figure 1c: Assumed Uu Stratum Model 



Radio interface protocol architecture 



Radio Link Control (RLC), Packet Data 



5.1 Overall protocol structure 

The radio interface is layered into three protocol layers: 

- the physical layer (LI), 

- the data link layer (L2), 

network layer (L3). 

Layer 2 is split into following sublayers: Medium Access Control (MAC), 
Convergence Protocol (PDCP) and Broadcast/Multicast Control (BMC). 

Layer 3 and RLC are divided into Control (C-) and User (U-) planes. PDCP and BMC exist in the U-plane only. 

In the C-plane, Layer 3 is partitioned into sublayers where the lowest sublayer, denoted as Radio Resource Control 
(RRC), interfaces with layer 2 and terminates in the UTRAN. The next sublayer provides Duplication avoidance' 
functionality as specified in [13]. - It terminates in the CN but is part of the Access Stratum; it provides the Access 
Stratum Services to higher layers. The higher layer signalling such as Mobility Management (MM) and Call Control 
(CC) are assumed to belong to the non-access stratum, and therefore not in the scope of 3GPP TSG RAN. On the 
general level, the protocol architecture is similar to the current ITU-R protocol architecture, ITU-R M. 1035. 

Figure 2 shows the radio interface protocol architecture. Each block in Figure 2 represents an instance of the respective 
protocol. Service Access Points (SAP) for peer-to-peer communication are marked with circles at the interface between 
sublayers. The SAP between MAC and the physical layer provides the transport channels (cf. Section 5.2. 1.1). The 
SAPs between RLC and the MAC sublayer provide the logical channels (cf. Section 5.3.1.1.1). In the C-plane, the 
interface between Duplication avoidance' and higher L3 sublayers (CC, MM) is defined by the General Control (GC), 
Notification (Nt) and Dedicated Control (DC) SAPs. 
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Also shown in the figure are connections between RRC and MAC as well as RRC and LI providing local inter-layer 
control services. An equivalent control interface exists between RRC and the RLC sublayer, between RRC and the 
PDCP sublayer and between RRC and BMC sublayer. These interfaces allow the RRC to control the configuration of 
the lower layers. For this purpose separate Control SAPs are defined between RRC and each lower layer (PDCP, RLC, 
MAC, and LI). 

The RLC sublayer provides ARQ functionality closely coupled with the radio transmission technique used. There is no 
difference between RLC instances in C and U planes. 

The UTRAN can be requested by the CN to prevent all loss of data (i.e. independently of the handovers on the radio 
interface), as long as the Iu connection point is not modified. This is a basic requirement to be fulfilled by the UTRAN 
retransmission functionality as provided by the RLC sublayer. 

However, in case of the Iu connection point is changed (e.g. SRNS relocation, streamlining), the prevention of the loss 
of data may not be guaranteed autonomously by the UTRAN but relies on Duplication avoidance* functions in the CN 

C-plane signalling U-plane information 

Duplication avoidance 



UuS boundary 




L2/PDCP 



L2/BMC 



L2/RLC 



Logical 
Channels 

L2/MAC 

Transport 
Channels 

LI 



Figure 2: Radio Interface protocol architecture (Service Access Points marked by circles) 

5.1.1 Service access points and sen/ice primitives 

Each layer provides services at Service Access Points (SAPs). A service is defined by a set of service primitives 
(operations) that a layer provides to upper layer(s). 



Control services 
are provided at Control 



, allowing the RRC layer to control lower layers locally (i.e. not requiring peer-to-peer communication) 
Zontrol SAPs (C-SAP). Note that C-S AP primitives can bypass one or more sublayers, see Figure 2. 
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In the radio interface protocol specifications, the following naming conventions for primitives shall be applicable: 

- Primitives provided by SAPs between adjacent layers shall be prefixed with the name of the service-providing 
layer, i.e. PHY, MAC, RLC, PDCP. BMC or UUS. 

Primitives provided by SAPs to an application shall be prefixed with the name of the service-providing layer, i.e. 
RRC. 

Primitives provided by Control SAPs, in addition to the name of the service-providing layer, shall be prefixed 
with a "C\ i.e. CPHY, CMAC, CRLC, CPDCP or CBMC. 

This principle leads to the following notations, where <Type> corresponds to request, indication, response or confirm 
type of primitives: 

Primitives between PHY and MAC: 

PHY- <Generic name> - <Type> 
Primitives between PHY and RRC (over C-SAP): 

CPHY- <Generic name> - <Type> 
Primitives between MAC and RLC: 

MAC- <Generic name> - <Type> 
Primitives between MAC and RRC (over C-SAP): 

CMAC- <Generic name> - <Type> 
Primitives between RLC and upper layers, between RLC and RRC for data transfer and between RLC and PDCP: 

RLC- <Generic name> - <Type> 
Primitives between RLC and RRC for control of RLC (over C-SAP): 

CRLC- <Generic name>- <Type> 
Primitives above Uu Stratum: 

UUS- <Generic name> - <Type> 
Primitives between PDCP and non-access stratum: 

PDCP- <Generic name> - <Type> 
Primitives between PDCP and RRC (over C-SAP): 

CPDCP- <Generic name> - <Type> 
Primitives between BMC and upper layer: 

BMC- <Generic name> - <Type> 
Primitives between BMC and RRC for control of BMC (over C-SAP): 

CBMC- <Generic name> - <Type> 
In this model, some UUS primitives map directly to RLC primitives without intervening function. 

5.2 Layer 1 Services and Functions 

This section shall provide an overview on services and functions provided by the physical layer. A detailed description 
of Layer 1 general requirements can be found in 3GPP TS 25.302 [4]. 
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5.2.1 L1 Services 

The physical layer offers information transfer services to MAC and higher layers. The physical layer transport services 
are described by how and with what characteristics data are transferred over the radio interface. An adequate term for 
this is 'Transport Channel'. 

NOTE: This should be clearly separated from the classification of what is transported, which relates to the 

concept of logical channels. Thus DCH is used to denote that the physical layer offers the same type of 
service for both control and traffic. 

5.2.1.1 Transport channels 

A general classification of transport channels is into two groups: 

common transport channels (where there is a need for inband identification of the UEs when particular UEs are 
addressed) and 

dedicated transport channels (where the UEs are identified by the physical channel, i.e. code and frequency for 
FDD and code, time sibt and frequency for TDD). 

Common transport channel types are (a more detailed description can be found in [4]): 

Random Access Channel (RACH) 

A contention based uplink channel used for transmission of relatively small amounts of data, e.g. for initial 
access or non-real-time dedicated control or traffic data. 

- ODMA Random Access Channel (ORACH) 

A contention based channel used in relay link. 

- Common Packet Channel (CPCH) 

A contention based channel used for transmission of bursty data traffic. This channel only exists in FDD mode 
and only in the uplink direction. The common packet channel is shared by the UEs in a cell and therefore, it is a 
common resource. The CPCH is fast power controlled. 

Forward Access Channel (FACH) 

Common downlink channel without closed-loop power control used for transmission of relatively small amount 
of data. 

- Downlink Shared Channel (DSCH) 

A downlink channel shared by several UEs carrying dedicated control or traffic data. 

- Uplink Shared Channel (USCH) 

An uplink channel shared by several UEs carrying dedicated control or traffic data, used in TDD mode only. 

- Broadcast Channel (BCH) 

A downlink channel used for broadcast of system information into an entire cell. 
Synchronisation Channel (SCH) 

A downlink channel used for broadcast of synchronisation information into an entire cell in TDD mode. 

NOTE: The SCH transport channel is defined for the TDD mode only. In the FDD mode, a synchronisation 
channel is defined as a physical channel. This channel however should not be confused with the SCH 
transport channel defined above. 

- Paging Channel (PCH) 
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A downlink channel used for broadcast of control information into an entire cell allowing efficient UE sleep 
mode procedures. Currently identified information types are paging and notification. Another use could be 
UTRAN notification of change of BCCH information. 

Dedicated transport channel types are: 

- Dedicated Channel (DCH) 

A channel dedicated to one UE used in uplink or downlink. 

- Fast Uplink Signalling Channel (FAUSCH) 

An uplink channel used to allocate dedicated channels in conjunction with FACH. 

- ODMA Dedicated Channel (ODCH) 

A channel dedicated to one UE used in relay link. 

To each transport channel (except for the FAUSCH, since it only conveys a reservation request), there is an associated 
Transport Format (for transport channels with a fixed or slow changing rate) or an associated Transport Format Set (fo 
transport channels with fast changing rate). A Transport Format is defined as a combination of encodings, interleaving 
bit rate and mapping onto physical channels (see 3GPP TS 25.302 [4] for details). A Transport Format Set is a set of 
Transport Formats. E.g., a variable rate DCH has a Transport Format Set (one Transport Format for each rate), wherea 
a fixed rate DCH has a single Transport Format. 



The physical layer performs the following main functions: 

- Macrodiversity distribution/combining and soft handover execution 

- Error detection on transport channels and indication to higher layers 

- FEC encoding/decoding and interleaving/deinterleaving of transport channels 

- Multiplexing of transport channels and demultiplexing of coded composite transport channels 
Rate matching 

Mapping of coded composite transport channels on physical channels 

- Power weighting and combining of physical channels 

Modulation and spreading/demodulation and despreading of physical channels 

- Frequency and time (chip, bit, slot, frame) synchronisation 

- Measurements and indication to higher layers (e.g. FER, SIR, interference power, transmit power, etc.) 
Closed-loop power control 

RF processing 

- Support of timing advance on uplink channels (TDD only) 

- Support of Uplink Synchronisation as defined in [12] (TDD only) 



5.2.2 



L1 Functions 





Functions 



5.3.1 MAC Services and Functions 

This section provides an overview on services and functions provided by the MAC sublayer. A detailed description of 
the MAC protocol is given in 3GPP TS 25.32 1 [7 J. 
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5.3.1.1 



MAC Services to upper layers 



Data transfer. This service provides unacknowledged transfer of MAC SDUs between peer MAC entities. This 
service does not provide any data segmentation. Therefore, segmentation/reassembly function should be 
achieved by upper layer. 

Reallocation of radio resources and MAC parameters. This service performs on request of RRC execution of 
radio resource reallocation and change of MAC parameters, i.e. reconfiguration of MAC functions such as 
change of identity of UE, change of transport format (combination) sets, change of transport channel type. In 
TDD mode, in addition, the MAC can handle resource allocation autonomously. 

Reporting of measurements. Local measurements such as traffic volume and quality indication are reported to 
RRC. 



5.3.1.1.1 



Logical channels 



Control Channel (CCH) 



The MAC layer provides data transfer services on logical channels. A set of logical channel types is defined for 
different kinds of data transfer services as offered by MAC Each logical channel type is defined by what type of 
information is transferred. 

A general classification of logical channels is into two groups: 

- Control Channels (for the transfer of control plane information) 

- Traffic Channels (for the transfer of user plane information) 
The configuration of logical channel types is depicted in Figure 3. 

! Synchronisation Control Channel (SCCH) 

- — ; — Broadcast Control Channel (BCCH) 

Paging Control Channel (PCCH) 

Dedicated Control Channel (DCCH) 

— ■ Common Control Channel (CCCH) 

: Shared Channel Control Channel (SHCCH) 

— ODMA Dedicated Control Channel (ODCCH) 

ODMA Common Control Channel (OCCCH) 



Traffic Channel (TCH) 



* Dedicated Traffic Channel (DTCH) 

- ODMA Dedicated Traffic Channel (ODTCH) 

• Common Traffic Channel (CTCH) . 



Figure 3: Logical channel structure 



Control Channels 

Control channels are used for transfer of control plane information only. 
Synchronisation Control Channel (SCCH) 

A downlink channel for broadcasting synchronisation information (information about the location and structure of the 
BCCH) in case of TDD operation. 
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Broadcast Control Channel (BCCH) 

A downlink channel for broadcasting system control information. 
Paging Control Channel (PCCH) 

A downlink channel that transfers paging information. This channel is used when the network does not know the 
location cell of the UE, or, the UE is in the cell connected state (utilising UE sleep mode procedures). 

Common Control Channel (CCCH) 

Bi-directional channel for transmitting control information between network and UEs. This channel is commonly used 
by the UEs having no RRC connection with the network and by the UEs using common transport channels when 
accessing a new cell after cell reselection. 

Dedicated Control Channel (DCCH) 

A point-to-point bi-directional channel that transmits dedicated control information between a UE and the network. This 
channel is established through RRC connection setup procedure. 

Shared Channel Control Channel (SHCCH) 

Bi-directional channel that transmits control information for uplink and downlink shared channels between network and 
UEs. This channel is for TDD only. 

ODMA Common Control Channel (OCCCH) 

Bi-directional channel for transmitting control information between UEs. 
ODMA Dedicated Control Channel (ODCCH) 

A point-to-point bi-directional channel that transmits dedicated control information between UEs. This channel is 
established through RRC connection setup procedure. 

Traffic Channels 

Traffic channels are used for the transfer of user plane information only. 
Dedicated Traffic Channel (DTCH) 

A Dedicated Traffic Channel (DTCH) is a point-to-point channel, dedicated to one UE, for the transfer of user 
information. A DTCH can exist in both uplink and downlink. 

ODMA Dedicated Traffic Channel (ODTCH) 

An ODMA Dedicated Traffic Channel (ODTCH) is a point-to-point channel, dedicated to one UE, for the transfer of 
user information between UEs. An ODTCH exists in relay link. 

Common Traffic Channel (CTCH) 

A point-to-multipoint unidirectional channel for transfer of dedicated user information for all or a group of specified 
UEs. . 

5.3.1 .1 .2 Mapping between logical channels and transport channels 

The following connections between logical channels and transport channels exist: 

- SCCH is connected to SCH 

- BCCH is connected to BCH and may also be connected to FACH 

- PCCH is connected to PCH 

- CCCH is connected to RACH and FACH 

- SHCCH is connected to RACH and USCH/FACH and DSCH 
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DTCH can be connected to either RACH and FACH T 10 RACH and DSCH, to DCH and DSCH, to a DCH, a 
CPCH (FDD only) or to USCH (TDD only) 

- CTCH is connected to FACH. 

- DCCH can be connected to either RACH and FACH, to RACH and DSCH, to DCH and DSCH, to a DCH, a 
CPCH (FDD only) to FAUSCH, CPCH (FDD only), or to USCH (TDD only). 

The mappings as seen from the UE and UTRAN sides are shown in Figure 4 and Figure 5 respectively. Figure 6 
illustrates the mapping from the UE in relay operation. Note that ODMA logical channels and transport channels are 
employed only in relay link transmissions (i.e. not used for uplink or downlink transmissions on the UE-UTRAN radio 
interface). 
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Figure 4: Logical channels mapped onto transport channels, seen from the UE side 
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Figure 5: Logical channels mapped onto transport channels, seen from the UTRAN side 
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Figure 6: Logical channels mapped onto transport channels, seen from the UE side (relay only) 
5.3.1.2 MAC functions 

The functions of MAC include: 

Mapping between logical channels and transport channels. The MAC is responsible for mapping of logical 
channel(s) onto the appropriate transport channel(s). 

Selection of appropriate Transport Format for each Transport Channel depending on instantaneous 
source rate. Given the Transport Format Combination Set assigned by RRC, MAC selects the appropriate 
transport format within an assigned transport format set for each active transport channel depending on source 
rate. The control of transport formats ensures efficient use of transport channels. 

Priority handling between data flows of one UE. When selecting between the Transport Format Combinations 
in the given Transport Format Combination Set, priorities of the data flows to be mapped onto the corresponding 
Transport Channels can be taken into account. Priorities are e.g. given by attributes of Radio Bearer services and 
RLC buffer status. The priority handling is achieved by selecting a Transport Format Combination for which 
high priority data is mapped onto LI with a "high bit rate" Transport Format, at the same time letting lower 
priority data be mapped with a "low bit rate" (could be zero bit rate) Transport Format. Transport format 
selection may also take into account transmit power indication from Layer I. 

Priority handling between UEs by means of dynamic scheduling. In order to utilise the spectrum resources 
efficiently for bursty transfer, a dynamic scheduling function may be applied. MAC realises priority handling on 
common and shared transport channels. Note that for dedicated transport channels, the equivalent of the dynamic 
scheduling function is implicitly included as part of the reconfiguration function of the RRC sublayer. 

NOTE: In the TDD mode the data to be transported are represented in terms of sets of resource units. 

Identification of UEs on common transport channels. When a particular UE is addressed on a common 
downlink channel, or when a UE is using the RACH, there is a need for inband identification of the UE. Since 
the MAC layer handles the access to, and multiplexing onto, the transport channels, the identification 
functionality is naturally also placed in MAC. 

Multiplexing/demultiplexing of higher layer PDUs into/from transport blocks delivered to/from the 
physical layer on common transport channels. MAC should support service multiplexing for common 
transport channels, since the physical layer does not support multiplexing of these channels. 

Multiplexing/demultiplexing of higher layer PDUs into/from transport block sets delivered to/from the 
physical layer on dedicated transport channels. The MAC allows service multiplexing for dedicated transport 
channels. This function can be utilised when several upper layer services (e.g. RLC instances) can be mapped 
efficiently on the same transport channel. In this case the identification of multiplexing is contained in the MAC 
protocol control information. 

Traffic volume monitoring. Measurement of traffic volume on logical channels and reporting to RRC. Based 
on the reported traffic volume information, RRC performs transport channel switching decisions. 
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Dynamic Transport Channel type switching. Execution of the switching between common and dedicated 
transport channels based on a switching decision derived by RRC. 

Ciphering. This function prevents unauthorised acquisition of data. Ciphering is performed in the MAC layer 
for transparent RLC mode. 

Access Service Class selection for RACH transmission. The RACH resources (i.e. access slots and preamble 
signatures for FDD. timeslot and channelisation code for TDD) may be divided between different Access 
Service Classes in order to provide different priorities of RACH usage. In addition it is possible for more than 
one ASC or for all ASCs to be assigned to the same access slotysignature space. Each access service class will 
also have a set of back-off parameters associated with it, some or all of which may be broadcast by the network. 
The MAC function applies the appropriate back-off and indicates to the PHY layer Lhe RACH partition 
associated to a given MAC PDU transfer. 

5.3.2 RLC Services and Functions 

This section provides an overview on services and functions provided by the RLC sublayer. A detailed description of 
the RLC protocol is given in 3GPP TS 25.322 [8]. 

5.3.2.1 Services provided to the upper layer 

- RLC connection establishment/release. This service performs establishment/release of RLC connections. 

- Transparent data transfer. This service transmits higher layer PDUs without adding any protocol information, 
possibly including segmentation/reassembly functionality. 

- Unacknowledged data transfer. This service transmits higher layer PDUs without guaranteeing delivery to the 
peer entity. The unacknowledged data transfer mode has the following characteristics: 

- Detection of erroneous data: The RLC sublayer shall deliver only those SDUs to the receiving higher layer 
that are free of transmission errors by using the sequence-number check function. 

- Unique delivery: The RLC sublayer shall deliver each SDU only once to the receiving upper layerusing 
duplication detection function. 

- Immediate delivery: The receiving RLC sublayer entity shall deliver a SDU to the higher layer receiving 
entity as soon as it arrives at the receiver. 

- Acknowledged data transfer. This service transmits higher layer PDUs and guarantees delivery to the peer 
entity. In case RLC is unable to deliver the data correctly, the user of RLC at the transmitting side is notified. For 
this service, both in-sequence and out-of-sequence delivery are supported. In many cases a higher layer protocol 
can restore the order of its PDUs. As long as the out-of-sequence properties of the lower layer are known and 
controlled (i.e. the higher layer protocol will not immediately request retransmission of a missing PDU) allowing 
out-of-sequence delivery can save memory space in the receiving RLC. The acknowledged data transfer mode 
has the following characteristics: 

Error-free delivery: Error-free delivery is ensured by means of retransmission. The receiving RLC entity 
delivers only error-free SDUs to the higher layer. 

- Unique delivery: The RLC sublayer shall deliver each SDU only once to the receiving upper layer using 
duplication detection function. 

- In-sequence delivery: RLC sublayer shall provide support for in-order delivery of SDUs, i.e., RLC sublayer 
should deliver SDUs to the receiving higher layer entity in the same order as the transmitting higher layer 
entity submits them to the RLC sublayer. 

- Out-of-sequence delivery: Alternatively to in-sequence delivery, it shall also be possible to allow that the 
receiving RLC entity delivers SDUs to higher layer in different order than submitted to RLC sublayer at the 
transmitting side. 

- QoS setting. The retransmission protocol shall be configurable by layer 3 to provide different levels of QoS. 
This can be controlled. 
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Notification of unrecoverable errors. RLC notifies the upper layer of errors that cannot be resolved by RLC " 
itself by normal exception handling procedures, e.g. by adjusting the maximum number of retransmissions 
according to delay requirements. 

There is a single RLC connection per Radio Bearer. 

5.3.2.2 RLC Functions 

- Segmentation and reassembly. This function performs segmentation/reassembly of variable-length higher layer 
PDUs into/from smaller RLC Payload Units (PUs). The RLC PDU size is adjustable to the actual set of transport 
formats. 

NOTE: Multiple PUs in a RLC PDU is not supported in Release 99. For Release 99 an RLC PDU will include 
only a single RLC PU. 

Concatenation. If the contents of an RLC SDU do not fill an integer number of RLC PUs, the first segment of 
the next RLC SDU may be put into the RLC PU in concatenation with the last segment of the previous RLC 
SDU. 

Padding. When concatenation is not applicable and the remaining data to be transmitted does not fill an entire 
RLC PDU of given size, the remainder of the data field shall be filled with padding bits. 

- Transfer of user data. This function is used for conveyance of data between users of RLC services. RLC 
supports acknowledged, unacknowledged and transparent data transfer. QoS setting controls transfer of user 
data. 

Error correction. This function provides error correction by retransmission (e.g. Selective Repeat, Go Back N, 
or a Stop-and-Wait ARQ) in acknowledged data transfer mode. 

In-sequence delivery of higher layer PDUs. This function preserves the order of higher layer PDUs that were 
submitted for transfer by RLC using the acknowledged data transfer service. If this function is not used, out-of- 
sequence delivery is provided. 

- Duplicate Detection. This function detects duplicated received RLC PDUs and ensures that the resultant higher 
Layer PDU is delivered only once to the upper layer. 

- Flow control. This function allows an RLC receiver to control the rate at which the peer RLC transmitting entity 
may send information. 

- Sequence number check (Unacknowledged data transfer mode). This function guarantees the integrity of 
reassembled PDUs and provides a mechanism for the detection of corrupted RLC SDUs through checking 
sequence number in RLC PDUs when they are reassembled into a RLC SDU. A corrupted RLC SDU will be 
discarded. 

Protocol error detection and recovery. This function detects and recovers from errors in the operation of the 
RLC protocol. 

- Ciphering. This function prevents unauthorised acquisition of data. Ciphering is performed in RLC layer for 
non-transparent RLC mode. 

- Suspend/resume function. Suspension and resumption of data transfer as in e.g. LAPDm (cf. GSM 04.05). 

5.3.3 PDCP Services and Function 

This section provides an overview on services and functions provided by the Packet Data Convergence Protocol 
(PDCP). A detailed description of the PDCP is given in 3GPP TS 25.323 [10]. 

5.3.3.1 PDCP Services provided to upper layers 

- Transmission and reception of Network PDUs in acknowledged* unacknowledged and transparent RLC mode. 
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5.3.3.2 PDCP Functions 

- Mapping of Network PDUs from one network protocol to one RLC entity. 

- Compression in the transmitting entity and decompression in the receiving entity of redundant Network PDU 
control information (header compression/ decompression). This may include TCP/IP header compression and 
decompression. 

5.3.4 Broadcast/Multicast Control - Services and functions 

This section provides an overview on services and functions provided by the BMC sublayer. A detailed description of 
the BMC protocol is given in 3GPP TS 25.324 [10]. 



5.3.4.1 BMC Services 

The BM-SAP provides a broadcast/multicast transmission service in the user plane on the radio interface for common 
user data in transparent or unacknowledged mode. 

5.3.4.2 BMC Functions 

- Storage of Cell Broadcast Messages 

The BMC stores the Cell Broadcast messages received over the CBC-RNC interface for scheduled transmission. 

- Traffic volume monitoring and radio resource request for CBS 

At the UTRAN side, the BMC calculates the required transmission rate for Cell Broadcast Service based on the 
messages received over the CBC-RNC interface, and requests for appropriate CTCH/FACH resources from 
RRC. 

- Scheduling of BMC messages 

The BMC receives scheduling information together with each Cell Broadcast message over the CBC-RNC- 
interface. Based on this scheduling information , at the UTRAN side, BMC generates schedule messages and 
schedules BMC message sequences accordingly. At the UE side, BMC evaluates the schedule messages and 
indicates scheduling parameters to RRC, which are used by RRC to configure the lower layers for CBS 
discontinuous reception. 

- Transmission of BMC messages to UE 

This function transmits the BMC messages (Scheduling and Cell Broadcast messages) according to schedule. 

- Delivery of Cell Broadcast messages to upper layer (NAS) 

This functions delivers the received Cell Broadcast messages to upper layer (NAS) in the UE. Only non- 
corrupted Cell Broadcast messages are delivered. 



5.3.5 Data flows through Layer 2 

Data flows through layer 2 are characterised by the applied data transfer modes on RLC (acknowledged, 
unacknowledged and transparent transmission) in combination with the data transfer type on MAC, i.e. whether or not a 
MAC header is required. The case where no MAC header is required is referred to as "transparent" MAC transmission. 
Acknowledged and unacknowledged RLC transmissions both require a RLC header. In unacknowledged transmission, 
only one type of unacknowledged data PDU is exchanged between peer RLC entities. In acknowledged transmission, 
both (acknowledged) data PDUs and control PDUs are exchanged between peer RLC entities. 

The resulting different data flow cases are illustrated in Figures 7 - 10. On the level of detail presented here, differences 
between acknowledged and unacknowledged RLC transmission are not visible. Acknowledged and unacknowledged 
RLC transmission is shown as one case, referred to as non-transparent RLC. 
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NOTE: The term "transparent transmission" is used here to characterise the case where a protocol, MAC or RLC- 
does not require any protocol control information (e.g. header). In transparent transmission mode, 
however, some protocol functions may still be applied. In this case an entity of the respective protocol 
must be present even when the protocol is transparent. For the RLC protocol the segmentation/reassembly 
function may be applied. This can be performed without segmentation header when a given higher layer 
PDU fits into a fixed number of RLC PDUs to be transferred in a given transmission time interval. In this 
case segmentation/reassembly follows predefined.ral^SpluiowAi|o^n(i|ing and receiving RLC entities. For 
instance in the user plane, the segmentation/reassembly function is needed for the case of real-time 
services using high and possibly variable bit rates. For such services higher layer PDUs shall be 
segmented into reasonably sized RLC PDUs of fixed length allowing efficient FCS error detection on the 
physical layer. The higher layer PDU can be reassembled by simply concatenating all RLC PDUs 
included in a transport block set as implied by the used transport format. 

Figure 7 and Figure 8 illustrate the data flows for transparent RLC with transparent and non-transparent MAC 
transmission, respectively. 

Figure 9 and Figure 10 illustrate the data flows for non-transparent RLC with transparent and non-transparent MAC 
transmission, respectively. 

For acknowledged RLC transmission mode, a single RLC PDU may include more than one segment (referred to as 
Payioad Unit, cf. TS 25.322 [8]) of RLC SDU. The feature of including multiple PUs into a PDU is not shown here in 
the data flow, as it is not supported for Release 99. 

A number of MAC PDUs shown in the figures shall comprise a transport block set. Note, however, that in all cases a 
transport block set must not necessarily match with a RLC SDU. The span of a transport block set can be smaller or 
larger than an RLC SDU. 

Each mapping between a logical channel and a transport channel as defined in Figure 4 and Figure 5 in combination 
with the respective RLC transmission mode implies a certain data flow which is specified on a general level in the 
following. 
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Figure 7: Data flow for transparent RLC and MAC 
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Figure 8: Data flow for transparent RLC and non-transparent MAC 
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Figure 9: Data flow for non-transparent RLC and transparent MAC 
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5.3.5.1 



Figure 10: Data flow for non-transparent RLC and MAC 
Data flow for BCCH mapped to BCH 



All RRC PDUs transmitted on BCCH have a fixed length and fit into one RLC PDU (and, equivalently, MAC PDU, as 
defined by the transport format). No RLC header is needed, i.e. the transparent data transfer mode of RLC is applied. 

No MAC header is needed since only one BCCH logical channel is mapped onto a BCH. Figure 7 is applicable. 

5.3.5.2 Data flow for BCCH mapped to FACH 

No RLC header is needed; i.e. the transparent data transfer mode of RLC is applied. A MAC header is required for 
identification of the logical channel carried by the FACH. The data flow shown in Figure 8 is applicable. 

5.3.5.3 Data flow for PCCH mapped to PCH 

No RLC or MAC header is needed, i.e. the data flow in Figure 7 is applicable. 

5.3.5.4 Data flow for SCCH mapped to SCH 

Same data flow is applicable as for BCCH mapped to BCH. Applied in TDD mode only. A MAC header is not needed. 
The data flow shown in Figure 7 or Figure 9 applies, depending on applied RLC transmission mode. 



5.3.5.5 



Data flow for CCCH mapped to FACH/RACH 



For CCCH, transparent transmission mode on RLC is employed on the uplink (when mapped to RACH). 
Unacknowledged transmission mode on RLC is employed on the downlink (when mapped to FACH). A MAC header is 
used for logical channel identification (CCCH, CTCH, SHCCH, DCCH, DTCH). If the transparent RLC transfer mode 
is applied, the data flow Figure 8 is applicable. If the unacknowledged RLC transfer mode is applied, the data flow 
Figure 10 is applicable. 

5.3.5.6 Data flow for SHCCH mapped to USCH 

For SHCCH, transparent or unacknowledged transmission mode on RLC is employed. A MAC header may be used for 
logical channel identification (SHCCH, DCCH, DTCH). When no MAC header is used, SHCCH must be the only 
channel mapped to USCH/DSCH. If the transparent RLC transfer mode is applied, depending on whether the MAC 
header is needed or not, either the data flow Figure 7 or Figure 8 is applicable. If the unacknowledged RLC transfer 
mode is applied, depending on whether the MAC header is needed or not, either the data flow Figure 9 or Figure 10 is 
applicable. 
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5.3.5.7 Data flow for SHCCH mapped to FACH/RACH 

For SHCCH transparent or unacknowledged transmission mode on RLC is employed. A MAC header may be used for 
logical channel identification (CCCH, CTCH. SHCCH, DCCH, DTCH). When no MAC header is used, SHCCH must 
be\he only channel mapped to RACH/FACH. If the transparent RLC transfer mode is applied, depending on whether 
the MAC header is needed or not, either the data flow Figure 7 or Figure 8 is applicable. If the unacknowledged RLC 
transfer mode is applied, depending on whether the MAC header is needed or not, either the data flow Figure 9 or 
Figure 10 is applicable. 

5.3.5.8 Data flow for DCCH mapped to FACH/RACH 

For DCCH, both unacknowledged and acknowledged transmission mode on RLC is employed. A MAC header is 
mandatory for FACH/RACH carrying DCCH. The data flow shown in Figure 10 is applicable. 

5.3.5.9 Data flow for DCCH mapped to DSCH 

For DCCH both unacknowledged and acknowledged transmission mode on RLC is employed. A MAC header is 
mandatory when DCCH is mapped to a DSCH for FDD mode, i.e. the data flow in Figure 10 is applicable. For TDD a 
MAC header is optional, i.e. either the data flow in Figure 9 or Figure 10 is applicable. 

5.3.5.10 Data flow for DCCH mapped to USCH 

For DCCH, both unacknowledged and acknowledged transmission mode on RLC is employed. A MAC header is 
needed if DCCH and DTCH logical channels are multiplexed in MAC before mapping to a USCH, i.e. either the data 
flow in Figure 9 or Figure 10 is applicable. 

5.3.5.1 1 Data flow for DCCH mapped to CPCH 

For DCCH mapped to CPCH, unacknowledged or acknowledged transmission modes on RLC are employed. The MAC 
header is needed for logical channel service multiplexing. Figure 10 is the applicable data flow to this case.^ 

5.3.5.12 Data flow for DTCH (non-transparent RLC) mapped to FACH/RACH 

Mapping to FACH/RACH implies a DTCH with acknowledged or unacknowledged transmission on RLC. A MAC 
header is mandatory for FACH/RACH when carrying DTCH. The data flow shown in Figure 10 is applicable. 

5.3.5.13 Data flow for DTCH (non-transparent RLC) mapped to DSCH 

Mappino to DSCH implies a DTCH with acknowledged or unacknowledged transmission on RLC. A MAC header is 
mandatory when DTCH is mapped to a DSCH in FDD mode, i.e. the data flow in Figure 10 is applicable. In TDD mode 
a MAC header is optional, i.e. either the data flow in Figure 9 or Figure 10 is applicable. 

5.3.5.14 Data flow for DTCH (non-transparent RLC) mapped to USCH 

Mapping to USCH implies a DTCH with acknowledged or unacknowledged transmission on RLC. A MAC header is 
needed if DCCH and DTCH logical channels are multiplexed in MAC before mapping to a USCH, i.e. either the data 
flow in Figure 9 or Figure 10 is applicable. 

5.3.5.15 Data flow for DTCH (transparent RLC) mapped to DCH 

Continuous DTCH data stream is segmented into transport blocks on RLC and mapped on a DCH transport channel on 
MAC The transport block size is naturally implied by the data rate. Both RLC and MAC sublayers are transparent, i.e. 
no protocol control information is added, when no multiplexing of DTCH on MAC is applied. The data flow shown in 
Figure 7 is applicable. If multiplexing on MAC is performed, a MAC header is needed, and Figure 8 appl.es. 
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5.3.5.16 Data flow for DTCH (non-transparent RLC) mapped to DCH 

In this case acknowledged or unacknowledged transmission on RLC is applied. A MAC header is needed only if 
multiple DTCH logical channels are multiplexed in MAC before mapping to a DCH, i.e. either the data flow in Figure 9 
or Figure 10 is applicable. 

5.3.5.17 Data flow for DTCH (non-transparent RLC) mapped to CPCH. 

This case requires both non-transparent RLC and MAC operations. The data flow shown in Figure 10 is applicable. 

5.3.5.18 Data flow for DCCH mapped to DCH 

In this case non-transparent or transparent transmission mode on RLC is applied. A MAC header is needed only if 
DCCH and DTCH logical channels are multiplexed in MAC before mapping to a DCH, i.e. either the data flow in 
Figure 9 or Figure 10 is applicable. 

5.3.5.19 Data flow for CTCH mapped to FACH 

For CTCH, unacknowledged transmission mode on RLC is employed. A MAC header is used for logical channel 
identification (CCCH, CTCH, DCCH, DTCH). The data flow shown in Figure 10 is applicable. 

5.4 Layer 3 - Uu Stratum Services and Functions 

This section provides an overview on Layer 3 services and functions provided by the Uu Stratum as a whole. A detailed 
description of the RRC protocol is given in 3GPP TS 25.331 [11]. Examples of structured procedures involving RRC in 
Idle Mode and Connected Mode are described in 3GPP TS 25.303 [5] and 3GPP TS 25.304 [6], respectively. 

5.4.1 Uu Stratum services 

5.4.1.1 General Control 

The GC SAP provides an information broadcast service. This service broadcasts information to all UEs in a certain 
geographical area. The basic requirements from such service are: 

It should be possible to broadcast non-access stratum information in a certain geographical area. 

' - The information is transferred on an unacknowledged mode link. Unacknowledged mode means that the delivery 
of the broadcast information can not be guaranteed (typically no retransmission scheme is used). It seems 
reasonable to use an unacknowledged mode link since the information is broadcast to a lot of UEs and since 
broadcast information often is repeated periodically. 

- It should be possible to do repeated transmissions of the broadcast information (how it is repeated is controlled 
by the non-access stratum). 

The point where the UE received the broadcast information should be included, when the access stratum delivers 
broadcast information to the non-access stratum. 

5.4.1 .2 Notification 

The Nt SAP provides paging and notification broadcast services. The paging service sends information to a specific 
UE(s). The information is broadcast in a certain geographical area but addressed to a specific UE(s). The basic 
requirements from such service are: 

- It should be possible to broadcast paging information to a number of UEs in a certain geographical area. 

The information is transferred on an unacknowledged mode link. It is assumed that the protocol entities in non- 
access stratum handle any kind of retransmission of paging information. 

The notification broadcast service broadcasts information to all UEs in a certain geographical. The basic requirements 
from this service are typically the same as for the information broadcast service of the GC SAP: 
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- It should be possible to broadcast notification information in a certain geographical area. 

- The information is transferred on an unacknowledged mode link. 

5.4.1 .3 Dedicated Control 

The DC SAP provides services for establishment/release of a connection and transfer of messages using this connection. 
It should also be possible to transfer a message during the establishment phase. The basic requirements from the 
establishment/release services are: 

- It should be possible to establish connections (both point and group connections). 

- It should be possible to transfer an initial message during the connection establishment phase. This message 
transfer has the same requirements as the information transfer service. 

- It should be possible to release connections. 

The information transfer service sends a message using the earlier established connection. According to ( 1] it is possible 
to specify the quality of service requirements for each message. A finite number of quality of service classes will be 
specified in [1 ), but currently no class has been specified. In order to get an idea of the basic requirements, the CC and 
MM protocols in GSM are used as a reference. A GSM based core network is chosen since it is one main option for 
UMTS. Considering the existing GSM specification of CC and MM the basic requirements from the information 
transfer service provided by the°Duplication avoidance' function are (these are some of the services provided by the 
combination of a duplication layer, RR and the data link layer in GSM): 

In-sequence transfer of messages 

Messages are delivered to the NAS on the receiver side exactly in the order they have been submitted by the 
NAS on the sending side, without loss or duplication, except possibly for the loss of last messages in case of 
connection abortion. 

Priority handling 

If SMS messages should be transported through the control plane it should be possible to give higher priority to 
signalling messages. 

The CC and MM protocols also expect other services, which can not be supported by the current primitives of the DC 
SAP, e.g. indication of radio link failure. 

The information transfer service is provided by a combination of the services provided by the data link layer, RNC and 
the Duplication avoidance' function. 

5.4.2 RRC functions 

The Radio Resource Control (RRC) layer handles the control plane signalling of Layer 3 between the UEs and UTRAN. 
The RRC performs the following functions: 

- Broadcast of information provided by the non-access stratum (Core Network). The RRC layer performs 
system information broadcasting from the network to all UEs. The system information is normally repeated on a 
regular basis. The RRC layer performs the scheduling, segmentation and repetition. This function supports 
broadcast of higher layer (above RRC) information. This information may be cell specific or not. As an example 
RRC may broadcast Core Network location service area information related to some specific cells. 

- Broadcast of information related to the access stratum. The RRC layer performs system information 
broadcasting from the network to all UEs. The system information is normally repeated on a regular basis. The 
RRC layer performs the scheduling, segmentation and repetition. This function supports broadcast of typically 
cell-specific information. 

- Broadcast of ODMA relay node neighbour information. The RRC layer performs probe information 
broadcasting to allow ODMA routeing information to be collected. 

- Establishment, re-establishment, maintenance and release of an RRC connection between the UE and 
UTRAN. The establishment of an RRC connection is initialed by a request from higher layers at the UE side to 
establish the first Signalling Connection for the UE. The establishment of an RRC connection includes an 
optional cell re-selection, an admission control, and a layer 2 signalling link establishment. The release of an 
RRC connection can be initiated by a request from higher layers to release the last Signalling Connection for the 



3GPP 



3G TS 25.301 version 3.3^ 28 ^ 3G TS 25.301 V3.3.0 (1999-12) 

UE or by the RRC layer itself in case of RRC connection failure. In case of connection loss, the UE requests re- 
establishment of the RRC connection. In case of RRC connection failure, RRC releases resources associated 
with the RRC connection. 

- Collating ODMA neighbour list and gradient information. The ODMA relay node neighbour lists and their 
respective gradient information will be maintaining by the RRC. 

- Maintenance of number of ODMA relay node neighbours. The RRC will adjust the broadcast powers used 
for probing messages to maintain the desired number of neighbours. 

- Establishment, maintenance and release of a route between ODMA relay nodes. The establishment of an 
ODMA route and RRC connection based upon the routeing algorithm. 

- Interworking between the Gateway ODMA relay node and the UTRAN. The RRC layer will control the 
interworking with the standard TDD or FDD communication link between the Gateway ODMA relay node and 
the UTRAN. 

- Establishment, reconfiguration and release of Radio Bearers. The RRC layer can, on request from higher 
layers, perform the establishment, reconfiguration and release of Radio Bearers in the user plane. A number of 
Radio Bearers can be established to an UE at the same time. At establishment and reconfiguration, the RRC 
layer performs admission control and selects parameters describing the Radio Bearer processing in layer 2 ar*j 
layer 1, based on information from higher layers. 

- Assignment, reconfiguration and release of radio resources for the RRC connection. The RRC layer 
handles the assignment of radio resources (e.g. codes, CPCH channels) needed for the RRC connection including 
needs from both the control and user plane. The RRC layer may reconfigure radio resources during an 
established RRC connection. This function includes coordination of the radio resource allocation between 
multiple radio bearers related to the same RRC connection. RRC controls the radio resources in the uplink and. 
downlink such that UE and UTRAN can communicate using unbalanced radio resources (asymmetric uplink and 
downlink). RRC signals to the UE to indicate resource allocations for purposes of handover to GSM or other 
radio systems. 

- RRC connection mobility functions. The RRC layer performs evaluation, decision and execution related to 
RRC connection mobility during an established RRC connection, such as handover, preparation of handover to 
GSM or other systems, cell re-selection and cell/paging area update procedures, based on e.g. measurements 
done by the UE. 

- Paging/notification. The RRC layer can broadcast paging information from the network to selected UEs. Higher 
layers on the network side can request paging and notification. The RRC layer can also initiate paging during^an 
established RRC connection. - © 

- Routing of higher layer PDUs. This function performs at the UE side routing of higher layer PDUs to the 
correct higher layer entity, at the UTRAN side to the correct RANAP entity. 

- Control of requested QoS. This function shall ensure that the QoS requested for the Radio Bearers can be met. 
This includes the allocation of a sufficient number of radio resources. 

- UE measurement reporting and control of the reporting. The measurements performed by the UE are 
controlled by the RRC layer, in terms of what to measure, when to measure and how to report, including both 
UMTS air interface and other systems. The RRC layer also performs the reporting of the measure me nts°from the 
UE to the network. 

- Outer loop power control. The RRC layer controls setting of the target of the closed loop power control. 

- Control of ciphering. The RRC layer provides procedures for setting of ciphering (on/off) between the UE and 
UTRAN. 

- Slow DCA. Allocation of preferred radio resources based on long-term decision criteria. It is applicable only in 
TDD mode. 

Arbitration of radio resources on uplink DCH. This function controls the allocation of radio resources on 
uplink DCH on a fast basis, using a broadcast channel to send control information to all involved users. 

NOTE: This function is implemented in the CRNC. 
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Initial cell selection and re-selection in idle mode. Selection of (he most suitable cell based on idle mode 
measurements and cell selection criteria. 

Integrity protection. This function adds a Message Authentication Code (MAC-I) to those RRC messages that 
are considered sensitive and/or contain sensitive information. The mechanism how the MAC-I is calculated is 
described in TS 33.105 [14]. 

- Initial Configuration for CBS 

This function performs the initial configuration of the BMC sublayer. 

Allocation of radio resources for CBS ~. 

This function allocates radio resources for CBS based on traffic volume requirements indicated by BMC. The 
radio resource allocation set by RRC (i.e. the schedule for mapping of CTCH onto FACH/S-CCPCH) is 
indicated to BMC to enable generation of schedule messages. The resource allocation for CBS shall be broadcast 
as system information. 

- Configuration for CBS discontinuous reception 

This function configures the lower layers (LI, L2) of the UE when it shall listen to the resources allocated for 
CBS based on scheduling information received from BMC. 

- Timing advance control. The RRC controls the operation of timing advance. It is applicable only in TDD 
mode. 

5.5 Interactions between RRC and lower layers in the C plane 
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Figure 11: Interactions between RRC and lower layers 
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The RRC protocol controls and signals the allocation of radio resources to the UE. RRC allows MAC to arbitrate 
between users and Radio Bearers within the radio resource allocation. The RRC uses the measurements done by the 
lower layers to determine which radio resources that are available. Therefore it is a need for a measurement report from 
the UE RRC to the UTRAN RRC. Figure l I illustrates the principle. The local control and local measurements 
reporting is handled through the control SAPs between RRC and the lower layers. 



5.6 



Protocol termination 



This section specifies in which node of the UTRAN the radio interface protocols are terminated, i.e. where within 
UTRAN the respective protocol services are accessible. Dashed lines indicate those protocols whose presence is 
dependent on the service provided to upper layers. 

5.6.1 Protocol termination for DCH 

Figure 12 and Figure 13 show the protocol termination for DCH for the control and user planes, respectively. The part 
of physical layer terminating in the Serving RNC is the topmost macro-diversity combining and splitting function for 
the FDD mode. If no macrodiversity applies, the physical layer is terminated in Node B. 
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Figure 12: Protocol Termination for DCH, control plane 
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Figure 13: Protocol Termination for DCH, user plane 



5.6.2 Protocol termination for RACH/FACH 

Figure 1 4 and Figure 15 show the protocol termination for RACH/FACH for the control and user planes, respectively. 
Control plane termination refers to the case where RACH/FACH carry dedicated, common or shared control 
information (i.e. CCCH, DCCH or SHCCH, and in the downlink possibly also BCCH). User plane termination refers to 
the case where RACH/FACH carry dedicated user data (DTCH) (two alternatives cases, referred to as case B and C, are 
described in the Annex) or common user data (CTCH). 

It is assumed that macrodiversity/soft handover is not applied for RACH/FACH. Therefore, the physical layer 
terminates in Node B. For RACH/FACH carrying DCCH, MAC is split between Controlling and Serving RNC. RLC, 
and in the C plane also RRC terminate in the Serving RNC. Since Iur can support common channel data streams, the 
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users of that common channel can depend on different SRNCs. However, they depend on the same Controlling RNC. 
Therefore, for a given user, the Controlling RNC and the Serving RNC can he separate RNCs. 

For FACH carrying BCCH, MAC, RLC and RRC are terminated in the CRNC. 

For RACH/FACH carrying SHCCH, MAC, RLC and RRC are terminated in the Controlling RNC (TDD only). 
For RACH/FACH carrying CCCH, MAC, RLC and RRC are terminated in the RNC. 
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Figure 14: Protocol Termination for RACH/FACH, control plane 
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Figure 15: Protocol Termination for RACH/FACH, user plane 

5.6.3 Protocol termination for FAUSCH 

Protocol termination for the FAUSCH is the same as for the RACH in the control plane (see Figure 1 4), since FAUSCH 
is for control purposes only. 

5.6.4 Protocol termination for CPCH 

The protocol termination for CPCH is identical to the termination for RACH. Figure 14 (for DCCH) presents the 
control plane protocol termination. Figure 15 presents the user plane protocol termination. 

5.6.5 Protocol termination for DSCH 



5.6.5.1 



DSCH definition 



The DSCH is a resource that exists in downlink only. It has only impact on the physical and transport channel levels, so 
there is no definition of shared channel in the logical channels provided by MAC. 

The DSCH is a transport channel shared dynamically between several UEs. The DSCH is mapped to one or several 
physical channels such that a specified part of the downlink resources is employed. For the DSCH no macrodiversity is 
applied, i.e. a specific DSCH is transmitted in a single cell only. 

The following two DSCH cases are supported in Release 99, in the following denoted as cases A and B: 

Case A: The DSCH is defined is an extension to DCH transmission. DSCH related resource allocation is 
signalled utilising the transport format indication field (TFI) that will be mapped to the TFCI of the associated 
DCH. 
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- Case B: The DSCH is defined as a shared downlink channel for which resource allocation is performed by RRG 
in Controlling RNC. The allocation messages, including UE identification, are transmitted on SHCCH, which is 
mapped on RACH/FACH. Several DSCH can be multiplexed on a CCTrCH in the physical layer, the transport 
formats of the DSCHs have to be selected from the transport format combination set of this CCTrCH. Each 
CCTrCH is mapped on one or more PDSCHs. If the transport format combination subset of a CCTrCH contains 
more than one transport format combination, a TFCI can be transmitted inside the PDSCH, or blind detection 
can be applied in the UE. This case is supported for TDD only. 

NOTE: Cases A and B of DSCH can be employed concurrently for TDD (at the same time on a single PDSCH). 

Interleaving for the DSCH may be applied over a multiplicity of radio frames. Nevertheless, here the basic case is 
considered where the interleaving is rectangular for a given MAC PDU, and equal to one radio frame (10 ms). The 
framing is synchronised on the SCH. 

In every radio frame, one or several PDSCHs can be used in the downlink. Therefore, the DSCH supports code 
multiplexing. MAC multiplexing of different UEs shall not be applied within a radio frame, i.e. within one radio frame 
a PDSCH is assigned to a single UE. However, MAC multiplexing is allowed on a frame by frame basis, i.e. one 
PDSCH may be allocated to different UEs at each frame. 

Transport blocks on the DSCH may be of constant size, so that the Transport Block Set may be derived from the code 
allocated to each UE on the DSCH. For case B, the transport format combination set can change with each transmission 
time interval. 

5.6.5.2 Resource allocation and UE identification on DSCH 

The principles of capacity allocation and UE identification on the DSCH are described in more detail below. 



5.6.5.2.1 Case A (UE requires a downlink TFCI on a DPCCH) 

The TFCI of the dedicated physical channel may carry the information that a given code of the DSCH must be listened 
to by the UE. Fast power control can be applied per code based on the dedicated physical control channel, DPCCH. 

Alternatively, a UE may be requested on the DCH to listen to a DSCH for a given period of time, and to decode the data 
so that the address of the destination UE can be decoded. This does not require more TFCI values because signalling is 
done in layers 2 and 3. 

5.6.5.2.2 Case B (UE requires a downlink SHCCH) (TDD only) 

The information which physical downlink shared channels to listen to and when, is sent by RRC on the SHCCH logical 
channel which is mapped on RACH and USCH/FACH and DSCH. The transmitted Layer 3 messages contain 
information about the used PDSCHs and the timing of the allocation. 



5.6.5.3 Model of DSCH in UTRAN 

Figure 16 captures the working assumption on the Downlink Shared Channel (DSCH). The two RLCs point to logical 
channel (DTCH) specific RLC-entities of specific users while MAC refers to the provision of MAC sublayer functions 
for all users. 

The MAC sublayer of a DSCH is split between the Controlling RNC and SRNC For a given user, the RLC sublayer is 
terminated in its SRNC. Since Iur can support DSCH data streams, the users on that DSCH can depend on different 
SRNCs. For a given user, the Controlling RNC and the Serving RNC can be separate RNCs. The MAC in the network 
takes care of mapping downlink data either to a common channel (FACH, not shown in this figure), or to a DCH and/or 
the DSCH. 
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Figure 16: Model of downlink shared channel (DSCH) in UTRAN 



5.6.5.4 Protocol termination 

The protocol termination points for DSCH in control and user planes are presented in Figure 17 and Figure 18, 
respectively. 
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Figure 17: Protocol termination points for DSCH, control plane. 
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Figure 18: Protocol termination points for DSCH, user plane 

5.6.6 Protocol termination for transport channel of type USCH 



5.6.6.1 



USCH definition 



The USCH is only supported for TDD. It is a resource that exists in uplink only. It has only impact on the physical and 
transport channel levels, so there is no definition of shared channel in the logical channels provided by MAC. 

The USCH is a transport channel shared dynamically between several UEs. The USCH is mapped to one or several 
physical channels such that a specified part of the uplink resources is employed. 

The USCH is defined as a shared uplink channel for which resource allocation is performed by RRC in Controlling 
RNC. The allocation requests and allocation messages, including UE identification, are transmitted on SHCCH, which 
is mapped on RACH and USCH/FACH and DSCH. Several USCHs can be multiplexed on a CCTrCH in the physical 
layer, the transport formats of the USCHs have to be selected from the transport format combination set of this 
CCTrCH. Each CCTrCH is mapped on one or more PUSCHs. If the transport format combination subset of a CCTrCH 
contains more than one transport format combination, a TFCI can be transmitted inside the PUSCH, or blind detection 
can be applied in the Node B. 

Interleaving for the USCH may be applied over a multiplicity of radio frames. 

In every radio frame, one or several PUSCHs can be used in the uplink. Therefore, the USCH supports physical channel 
multiplexing. MAC multiplexing of different UEs shall not be applied within a radio frame, i.e. within one radio frame 
a PUSCH is assigned to a single UE. However, MAC multiplexing is allowed on a frame by frame basis, i.e. one 
PUSCH may be allocated to different UEs at each frame. 

The transport format combination set on the USCH can change with each transmission time interval. 



5.6.6.2 



Resource allocation and UE identification on USCH 



The information which physical uplink shared channels to transmit on and when is sent by RRC on the SHCCH logical 
channel which is mapped on RACH and USCH/FACH and DSCH. The transmitted Layer 3 messages contain 
information about the assigned PUSCHs and the timing of the allocation. 



5.6.6.3 



Model of USCH in UTRAN 



Figure 19 captures the working assumption on the Uplink Shared Channel (USCH). The two RLCs point to logical 
channel (DTCH) specific RLC-entities of specific users while MAC refers to the provision of MAC sublayer functions 
for all users. 

The MAC sublayer of a USCH is split between the Controlling RNC and SRNC. For a given user, the RLC sublayer is 
terminated in its SRNC. Since Iur can support USCH data streams, the users on that USCH can depend on different 
SRNCs. For a given user, the Controlling RNC and the Serving RNC can be separate RNCs. The MAC in the network 
takes care of mapping uplink data either from a common channel (RACH, not shown in this figure), DCH or the USCH. 
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Allocations of uplink capacity are requested by the UEs and signaled to the UEs on the SHCCH (Shared channel control 
channel) which is mapped on RACH and USCH/FACH and DSCH. 
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Figure 19: Model of uplink shared channel (USCH) in UTRAN (TDD only) 



5.6.6.4 



Protocol termination 



The protocol termination points for USCH in control and user planes are presented in Figure 20 and Figure 21, 
respectively. The USCH is for TDD only. 
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Figure 20: Protocol termination points for USCH, control plane (TDD only) 
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Figure 21: Protocol termination points for USCH, user plane (TDD only) 



5.6.7 Protocol termination for transport channel of type BCH 

System information on BCH can include information which is available only in Node B, and need to be updated very 
frequently (each 20-100 ms), such as uplink interference in the cell. Also, for the system information originating from 
the RNC, it is assumed that the updating of system information is at least one magnitude less (minutes) than the 
repetition frequency on the BCH (in the order of Is). The system information originating from the CRNC should be sent 
transparently to Node B, which then handles the repetition. Protocol termination for the BCH shall therefore be 
distributed between the Node B and the CRNC, resulting in less signalling on Iub and lower processor load. Note that 
the RLC sublayer is transparent for this transport channel type. 
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Figure 22: Protocol termination for BCH 

5.6.8 Protocol termination for transport channel of type PCH 

In order to enable co-ordinated scheduling between PCH and FACH/DSCH the corresponding MAC scheduling 
functions shall be allocated in the same node. MAC-c/sh is terminated in CRNC. A natural implication is that RLC and 
RRC also are terminated in CRNC. 

Note that the RLC sublayer is transparent for this channel. 
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Figure 23: Protocol termination for PCH 

5.6.9 Protocol termination for transport channel of type SCH 

The SCH transport channel is used in TDD mode only. Protocol termination for SCH is the same as for BCH as shown 
in Figure 22. 

5.6. 1 0 Protocol termination for ODCH 

Figure 24 and Figure 25 show the protocol termination for ODCH in the control and user planes, respectively. 
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Figure 24: Protocol Termination for the ODCH in the Control Plane 
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Figure 25: Protocol Termination for the ODCH in the User Plane 

NOTE: The current mechanisms and procedures carried out by the RLC and the MAC for the DCH will require 
modifications to enable them to handle the ODCH. 

5.6.11 Protocol termination for ORACH 

The protocol termination for ORACH for the control and user planes is illustrated in Figure 26 and Figure 27, 
respectively. The shown ODMA relay nodes may be either UE R , Seed, Root, or Gateway. 
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Figure 26: Protocol Termination for ORACH control plane 
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Figure 27: Protocol Termination for ORACH user plane 



6 User Identification and RRC Connection Mobility 
6.1 UE identification on the radio interface 

A Radio Network Temporary Identity (RNTI) is used as an UE identifier on RACH/FACH, RACH+CPCH/FACH or, 
for FDD mode, also on DSCH by the MAC protocol, or on PCH by the RRC, when a RRC connection exists. 

Definition of UE identifiers 

Two types of RNTIs exist. One is used within the Serving RNC and it is denoted by Serving RNC RNTI (S-RNTI), the 
other is used within a cell controlled by a CRNC, when applicable, and it is denoted by Cell RNTI (C-RNTI). 

S-RNTI is allocated for all UEs having a RRC connection. It is allocated by the Serving RNC and it is unique within the 
Serving RNC. S-RNTI is reallocated always when the Serving RNC for the RRC connection is changed and deallocated 
when the RRC connection is released. 

In addition for each UE having an RRC connection, there is an identifier of its current serving RNC, which is denoted 
as SRNC identifier. The SRNC identifier together with S-RNTI is a unique identifier of the RRC connection within 
PLMN. The combination of SRNC identifier and S-RNTI is referred to as U-RNTI (UTRAN Radio Network 
Temporary Identity) which is used on the radio interface. 

C-RNTI for an UE is allocated by a controlling RNC and it is unique within one cell controlled by the allocating 
CRNC. C-RNTI can be reallocated when a UE accesses a new cell with the cell update procedure. 

Usage of UE identifiers 

U-RNTI is allocated to an UE having a RRC connection. It identifies the UE within UTRAN and is used as a UE 
identifier in cell update, URA update, RRC connection reestablishment and (UTRAN originated) paging messages and 
associated responses on the radio interface. The SRNC identifier within the U-RNTI is used by the Controlling RNC to 
route the received uplink messages towards the Serving RNC. 

C-RNTI is used as a UE identifier in all other DCCH/DTCH common channel messages on the radio interface. 
NAS identifiers are used as the UE identifier in the initial access CCCH message on the radio interface. 
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6.2 UE connection to UTRAN 

The different levels of UE connection to UTRAN are listed below: 

- No signalling connection exist 

The UE has no relation to UTRAN, only to CN. For data transfer, a signalling connection has to be established. 

- Signalling connection exist 

There is a RRC connection between UE and UTRAN. The UE position can be known on different levels: 

. UTRAN Registration Area (URA) level 

The UE position is known on UTRAN registration area level. URA is a specified set of cell, which can be 
identified on the BCCH. 

- Cell level 

The UE position is known on cell level. Different channel types can be used for data transfer: 

- Common transport channels (RACH, FACH, CPCH, DSCH), 

- Dedicated transport channels (DCH); note that FAUSCH can be used to allocate a dedicated channel for 
data transmission. 

7 UE modes 

Two modes of operation are currently defined for the UE, idle mode and connected mode [5, 6]. 

After power on, the UE stays in idle mode until it transmits a request to establish an RRC connection. In idle mode the 
UE is identified by non-access stratum identities such as IMSI, TMSI and P-TMSI. In addition, the UTRAN has no own 
information about the individual idle mode UEs, and can only address e.g. all UEs in a cell or all UEs monitoring a 
specific paging occasion. 

The connected mode is entered when the RRC connection is established. A RRC connection is established between the 
UE and a RNC called SRNC. The UE is assigned a radio network temporary identity (U-RNTI and possibly in addition 
C-RNTI) to be used as UE identity on common transport channels. RRC connection is within a UTRAN identified with 
the U-RNTI. :; 

The UE leaves the connected mode and returns to idle mode when the RRC connection is released or at RRC 
connection failure. 

Reception of SMS cell broadcast can be done in both idle and connected mode. 

8 Ciphering 

The ciphering architecture is specified in TS 33.102 [15]. 

8.1 Location of ciphering function in the UTRAN protocol 
architecture 

The ciphering function is performed either in the RLC sub-layer or in the MAC sub-layer, according to the following 
rules: 

- If a logical channel is expected to be supported on common transport channel and has to be ciphered, it can not 
use the transparent mode of RLC (it should use the UM RLC mode instead). 

- If a logical channel is using a non-transparent RLC mode (AM or UM), ciphering is performed in the RLC sub- 
layer. 

- If a logical channel is using the transparent RLC mode, ciphering is performed in the MAC sub-layer (MAC-d 
entity). 
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According to this model, ciphering when applied is performed in the SRNC and the UE, and the context needed for 
ciphering (CK, HFN, etc.) is only known in SRNC and the UE. 

8.2 Input parameters to the ciphering algorithm 



8.2.1 



Overview 



When ciphering is performed in the RLC sub-layer, it performs the encryption/decryption of the ciphering unit of an 
RLC PDU, based on XOR combining with a mask obtained as an output of the ciphering algorithm. For UM RLC, the 
ciphering unit is defined as the UMD PDU minus the first octet. The first octet comprises the sequence number used as 
LSB of the COUNT parameter. For AM RLC, the ciphering unit is defined as the AMD PDU minus the two first octets. 
These two octets comprise the sequence number used as LSB of the COUNT parameter. 

When ciphering is performed in the MAC sub-layer, it performs the encryption/decryption of a MAC SDU (RLC PDU), 
based on XOR operation with a mask obtained as an output of the ciphering algorithm. 

Requirements and interfaces to the generic algorithm are specified in TS 33.105 and described in the following figure. 
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Figure 28: Ciphering algorithm and parameters 



8.2.2 Ciphering algorithms parameters 



8.2.2.1 



COUNT 



COUNT shall be at least 32 bits long. It is composed of a 'long* sequence number called Hyper Frame Number HFN, 
and a 'short* sequence number, which depends on the ciphering mode, as described below. There is one ciphering 
sequence per logical channel using AM or UM mode plus one for all logical channels using the transparent mode (and 
mapped onto DCH). 

The Hyper Frame Number (HFN) is initialised by the UE and signalled to the SRNC before ciphering is started. It is 
used as initial value for each ciphering sequence, and it is then incremented independently in each ciphering sequence, 
at each cycle of the 'short* sequence number. When a new RAB / logical channel is created during a RRC connection, 
the highest HFN value currently in use is incremented, and used as initial value for the ciphering sequence of this new 
logical channel. The highest HFN value used during a RRC connection (by any ciphering sequence) is stored in the 
USIM, and the UE initialises the new HFN for the next session with a higher number than the stored one. If no HFN 
value is available in USIM, the UE randomly selects a HFN value. 

Depending on the requirements (e.g. how many successive RRC Connections can use the same ciphering key), it may 
be sufficient to use only the most significant bits of HFN in the re-initialisation (and set LSBs implicitly to zero). This 
may be necessary at least if the HFN value needs to be included in the RRC Connection Request message. 

The 'short' sequence number is: 

- For RLC TM on DCH, the CFN of the UEFN is used and is independently maintained in UE MAC and SRNC 
MAC-d. The ciphering sequence number is identical to the UEFN. 
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For RLC UM and AM modes, the RLC sequence number is used, and is directly available in each RLC PDU at 
the receiver side (it is not ciphered). The HFN is incremented at each RLC SN cycle. 

The figure below presents some examples of the different COUNT parameters, assuming various sizes for the 'short' 
sequence numbers. This proposal permits to exchange a unique HFN and also to use a unique CSN size, which should 
permit to reduce the implementation complexity of the ciphering function. In this example, the HFN is 25 bits long, and 
only the 20 MSB are used for the CSN of the RLC AM mode. 
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Figure 29: Example of ciphering sequence number for all possible configurations 

8.2.2.2 Ciphering key, CK 

CK is established between the UE and SRNC during the authentication phase. In the two-key solution, the CS-domain 
bearers are ciphered with the most recent cipher key agreed between the user and the 3G-MSC (CK-CS). The PS- 
domain bearers are ciphered with the most recent cipher key agreed between the user and the3G-SGSN (CK-PS). The 
signalling link is ciphered with the most recent cipher key established between the user and the network, i.e., the 
youngest of CK-CS and CK-PS. 

To ensure performing the right ciphering function at the RLC and MAC layers, three conditions must be met: 

- Each logical traffic channel can only transfer the information either from CS-domain or PS-domain, but not from 
both. 

- RRC maps a given Radio Bearer to a given domain in order to derive the correct key to utilise for each RB. 

- The RLC and MAC layers receive the Radio Bearer IDs and CKs they should use from RRC. 

8.2.2.3 BEARER 

This parameter indicates the logical channel identity, which shall be unique within a RRC connection. It is used as input 
parameter of the ciphering algorithm to ensure that the same ciphering mask is not applied to two or more parallel 
logical channels having the same CK and same COUNT. Each logical channel is ciphered independently. 

8.2.2.4 Direction 

This parameter indicates the transmission direction (uplink/downlink). 

8.2.2.5 Length 

This parameter indicates the length of the keystream block (mask) to be generated by the algorithm. It is not an input to 
the keystream generation function. 
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Annex A (informative): 
Protocol termination 

This Annex describes protocol termination cases, which have been excluded from the initial UMTS release. These cases 
are captured here for information. They potentially may be considered for future releases. 

A.1 Alternative protocol termination for DCH 

Figure A.1 and Figure A.2 show an alternative protocol termination case for DCH for the control and user planes, 
respectively, referred to as Case B. This case would be applicable when macrodiversity at RNC level is not applied, i.e. 
especially for DCH in the TDD mode. 
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Figure A.1: Protocol Termination for DCH, control plane 

Case B: 
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Figure A.2: Protocol Termination for DCH, user plane 

A.2 Protocol termination for RACH/FACH 

Figure A.3 and Figure A.4 show two alternative protocol termination cases for RACH/FACH for the control and user 
planes, respectively, referred to as Case B and Case C. 

In case B, the physical layer, MAC and RLC terminate in Node B. 

In case C, the MAC sublayer is split between Node B, Controlling and Serving RNC. This would be the preferred 
solution when MAC in Node B shall provide acknowledgements to RACH messages and perform scheduling of FACH 
transmissions. 
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Figure A.3: Protocol Termination for RACH/FACH, control plane 
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Figure A.4: Protocol Termination for RACH/FACH, user plane 
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